The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over telecommunication networks (see 3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
FIG. 1 illustrates schematically the architecture for the IMS core network and its relationship to an IP-Connectivity Access Network (IP-CAN). In the IMS core network, Call/Session Control Functions (CSCFs) operate as SIP proxies, and interface with other entities such as Border Gateway Control Functions (BGCFs) and Media Resource Function Controllers (MRFCs) amongst others. The 3GPP architecture defines three types of CSCFs: a Proxy CSCF (P-CSCF) is the first point of contact within the IMS for a SIP terminal; a Serving CSCF (S-CSCF) provides services to the subscriber; and an Interrogating CSCF (I-CSCF) identifies the correct S-CSCF and forwards to that S-CSCF a request received from a SIP terminal via a P-CSCF.
The P-CSCF, as the initial SIP signalling contact point for subscribers, serves as a Back-to-Back User Agent (SIP B2BUA). The P-CSCF is responsible for forwarding SIP registration messages from the SIP terminal (e.g. the User Equipment (UE)), to the I-CSCF and subsequent call set-up requests and responses to the S-CSCF. The P-CSCF maintains the mapping between logical subscriber SIP URI address and physical UE IP address and a security association, for both authentication and confidentiality. When supporting IMS communication for a UE residing behind a NAT or when IP address translation is needed between the IP CAN and the IMS domain on the media path only, the P CSCF may include an IMS Application Level Gateway (IMS-ALG) function. The P-CSCF/IMS-ALG interacts with an IMS Access Gateway (IMS-AGW), over the Iq interface, for control of the boundary at the signalling and media layers (e.g. including pinhole firewall, Network Address and Port Translations (NAPT) lawful intercept and numerous other features).
The IMS-AGW controls the transport boundary at layers 3 and 4 between subscribers and the service provider's network. This function acts as a pinhole firewall and NAT device protecting the service provider's IMS network. It controls access by packet filtering on IP address/port and opening/closing gates (pinholes) into the network. It uses NAPT to hide the IP addresses/ports of the service elements in the IMS network. Other features include QoS packet marking, bandwidth and signalling rate policing, usage metering and QoS measurements for the media flows. The IMS-AGW sits at the boundary between an access network and a core network, at the core network side, and provides the functionality of a Core Border Gateway Function (C-BGF). It is also noted that the combination/integration of the P-CSCF and IMS-ALG at the signalling plane and the IMS-AGW at the media plane on the access side provides a Session Border Controller (SBC).
The Interconnect Border Control Function (IBCF) provides overall control of the boundary between different service provider networks. It provides security for the IMS network in terms of signaling information by implementing a Topology-Hiding Inter-network Gateway (THIG) sub-function, and IPv4-IPv6 inter-working by implementing an IMS ALG. The IMS ALG provides the necessary application function for SIP/SDP protocol stack in order to establish communication between IPv6 and IPv4 SIP applications. The IMS ALG receives an incoming SIP message, and changes the appropriate SIP/SDP parameters, translating the IPv6 address to IPv4 addresses and vice versa. The IBCF also invokes the Inter-Working Function (described below) when connecting non-SIP or non-IPv6 networks, and performs admission control and bandwidth allocation using local policies or via interface to PCRF elements. Lastly, the IBCF interacts with TrGW for control of the boundary at the transport layers including pinhole firewall, NAPT and numerous other features.
The Transition Gateway (TrGW) controls the transport boundary between service provider networks at layers 3 and 4 (e.g. with similar media functions as the IMS-AGW). The TrGW is located within the media path and controlled by the IBCF, provides network address/port translation and IPv4/IPv6 protocol translation, and supports proactive and reactive transcoding. The TrGW sits at the boundary between two core networks and provides the functionality of an Interconnection BGF (I-BGF). It is also noted that the combination/integration of the IBCF at the signalling plane and TrGW at the media plane on the interconnect side also provides a Session Border Controller (SBC).
In order to provide consumers with a comprehensive communication and interactive service experience on any web browser based device, telecommunications network operators want to be able to easily and quickly integrate and deploy services combining web and Internet applications with telecommunications network capabilities. It is therefore desired that telecommunication networks are able to support voice and video communications to and from web applications provided on User Equipment (UE). However, web browsers and web applications use protocols such as Hypertext Transfer Protocol (HTTP), Real-time Transport Protocol (RTP) in conjunction with the RTP Control Protocol (RTCP), and Real Time Messaging Protocol (RTMP) for delivering and controlling media. In contrast, the IMS core network makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers), and media transmissions are carried using the Real-time Transport Protocol (RTP). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session (e.g. port numbers, protocols, codecs).
In order to transmit media to and from a web browser/application provided at a UE through an IMS, an IMS-AGW at the boundary between the access network and the IMS core network may be required to act as a media gateway/server with respect to the UE, and may therefore be required handle the conversion between RTP used for media transmission by the IMS and some other media transport protocol that is used by the web browser/application provided at the UE, such as RTMP. However, it has been recognised here that media transport protocol conversion/translation between RTP and some alternative media transport protocol may not be straightforward to implement.
In this regard, SDP used by the IMS to describe and negotiate the media components of a session makes use of dynamically allocated RTP payload type numbers to identify the codec/media format(s) that can be used for the media, and one of these dynamically allocated RTP payload type numbers must be included in the payload type (PT) header field of corresponding RTP packets to identify the codec/media format that has been used for media carried in the payload. Therefore, when translating between RTP media packets and alternative media transport protocol media packets, it may not be possible to simply translate between an RTP payload type number and a statically defined codec identifier used by the alternative media transport protocol.
This is particularly problematic when the negotiation of a session between two participants/end points establishes that more one common codec is supported by the participants, and at least one of the participants uses an alternative media transport protocol other than RTP. For example, when a first UE that implements RTMP wants to exchange media with second UE via the IMS, and both the first UE and the second UE support a number of common codecs, the first UE and the second UE will agree on more than one commonly supported codec during the negotiation of the session. Whilst the P-CSCF/IMS-ALG that serves the first UE will then communicate the negotiated codecs to the IMS-AGW in H.248 commands sent over the Iq interface, by including the negotiated SDP in a H.248 command, the IMS-AGW will not know which of these commonly supported codecs the UEs will actually select to use for the media. Consequently, if the IMS-AGW subsequently receives an RTP packet that includes the dynamically allocated RTP payload type number of the selected common codec, the IMS-AGW will not be able to determine the codec to which this dynamically allocated RTP payload type number relates, and will therefore be unable to determine the statically defined codec identifier that needs to be included in a corresponding alternative media transport protocol media packet. Similarly, if the IMS-AGW receives an alternative media transport protocol packet that includes a statically defined codec identifier of the selected common codec, the IMS-AGW could determine the codec to which this statically defined codec identifier relates, but will be unable to determine the dynamically allocated RTP payload type number that needs to be included in a corresponding RTP packet.